バッドノウハウとは何だろうメモ

概要

自分が考える「バッドノウハウとは何か」まとめる。

バッドノウハウ a.k.a ただの残念

本来動くはずの実装に対する残念なバグを回避するための手段、実装。

たとえばガラケーの時は、端末ごとにサウンドプレイヤーの特性が～とかで、

APIは一辺倒なんだけど実挙動が違うとかあり得た。死ねば良いし実際死んだので文句は無い。

これをこじらせたのがAndroidで、APIとかスペックとかドキュメントに書いてある通りに

動かないことが稀によくある（悪意のある誇張

そこで、いろんな機種でも動くように、まあいろいろ錯誤するわけですよね。

その結果動くからそうね。良かったじゃん。

この努力はブラウザでもネイティブでもずっと今後もあるから、がんばれバッドノウハウ。(この項は改変されました)

CSSとかだと、reset.cssがバッドノウハウの域だと思う。超使ってたんですけど。

最近はこういうのがいいらしい (自分では使ってないけど職場で使ってる)

選択肢が生まれてバッドノウハウに降格的な。

[なぜリセットではなく Normalize.css を使うのか]

http://yomotsu.net/blog/2013/02/23/normalize.html

バッドノウハウ a.k.a Blocker、未来殺し

将来変更性に対するBlockerになり得る悪手。

例えば多方面に影響を与える状態値を末尾に持ってしまったり、

きちんとした上位設計をしない事で、

未来そのパーツや全体が持つ変更可能性とか修正可能性を奪い去ってしまうこと。

主犯を挙げるとこんなキーワードが出てくる

・アホなextend

・広範囲に及ぶ独自型のアホな乱用

・状態の下手な隠蔽

・プラグインなど、変更可能性が多い場所でのjarなど固定化(これはピンポイントにMavenをDisっていると思ってもらってOK)

・上記から産まれる密結合

症状としては、変更が大変。大変。

自分、疎結合大好きなんですが、

上記みたいな問題が出るのを、可能な限り遅らせることができる(主観です)

+

可能な限り修正を楽にする事が出来る(主観です)

ので、疎結合大好きです。

思うに、jarとかlibとかsoとかのライブラリはライブラリではなく、ファンクションとかそういう名前の方が良かったのでは。

x Library

o Function

そういう意味で、現代にはActorが居るのだと思っている。

Actorをクライアントサイドのコードで使ってみると良い。　すばらしいですよ。

全部Actorの海に沈むけど。

バッドノウハウ a.k.a 言語内言語機能拡張

言語機能自体を自己的に拡張する試み。

JavaScriptを使ってのFWに頻繁に出てくる。

何が悪いかと言うと、どこまでがその機能のための実装なのか、どこからがその機能を使った実装なのか、という

断面の喪失に繋がる。

例えば機能Fを言語Jに実装するとして、

言語Jで書く必要が有るわけで、、、

どこまでがその機能を実装するための実装で、どこからがソレ以外か、いつまで判然としてられると思う？っていう、

局所性の明示が自明に出来ないところが生まれる。

これが、損のはじまり、ここではこの種類のバッドノウハウの入り口だと思っている。

人間によるidentificationが必要、って時点で、もう駄目のエントリーポイントに立ってるんだとおもう。

で、

ここでドキュメンテーションが出てくる。モジュライズしようぜみたいな話がでてくる。

FWにしよう、1層限定のextendを使おう、など。

実利として、これらは効果があると思う。

でも、そもそも無くてすむ方が良いだろ、、、と思ってしまうんだけど。そういうのは甘えですかそうですか。

一度失った断面を取り戻すのはとても大変で、隅々までそれ全体を理解しないと、恐ろしい深度で実はつながってたりする。

時間が経つほど地下茎は全体に行き渡る。

再設計とか書き直しとか、こ、こんな機能の貧弱な言語でやってられるか！　俺は別の言語で書くぜとかそういう部類の所行が必要だと思う。

JSに関しては、そこでaltJSですよ、っていう。

なんかバッドノウハウっていうより悪手コレクションになった、、みたいな、、ああ一緒か。